The Debian project distributes software packages via its archive, propagated through a network of mirrors. This archive is organised in three areas, main, that contains the Debian system, and contrib and non-free, that contain accessory packages that are not Free. The packages in non-free contain files that have a proprietary license. The source packages in contrib contain only Free files, but produce binary packages that are either useless without the access to remote services, or contain non-Free files, or cause the installation of non-Free materials. The contrib area is an endless source of discussions, as it is not always easy to draw the line between what is usable and what is useless without remote services. I wonder if it would be better to replace the contrib area by a new priority level, remote , lower than extra. Packages that are entirely Free (source and binary) and that do not cause the installation of proprietary software would be fit for main. For the packages that can not function without non-Free software, given that the work to be done to free them is the same regardless whether the proprietary code is included in the source package (in non-free) or not (in contrib), I think that in both cases the package should be in non-free as it is not Free in practice. This would allow for a simple criterion: does the selection of a binary package trigger the installation of non-Free files? If yes, the package and its source belong to non-free. If not, they belong to main. Then, if they need to access a remote service that would not be possible to set up on a network where only Debian is available, their priority would be remote.

Thanks to Joey's present, umegaya is now hosted at Branchable. Thanks !

I finally manage to create an image of the Debian Installer automatically, with no key or password transiting on the Cloud or the network, and without using the ec2-api-tools, which are non-Free. Thanks to Eucalyptus for implementing the attribute InstanceInitiatedShutdownBehavior in euca2ools 2.1.2. In brief, I start a micro-instance with an additional volume, and I pass it a script for cloud-init, which will download the Installer on the volume and shut down the instance. Then, I register the volume as a machine image. Those machine images of the Installer are to be preseeded via instance metadata to install Debian on another volume. I am still struggling with the pre-configuration. More details will follow in the next article. In the meantime, here are the commands I a using. On the local computer, start an instance on the Cloud. Until #696595 is fixed and cloud-init is installed by default, I use a Ubuntu image.

HELPER_AMI=ami-7609bb77 # Ubuntu 12.04 LTS Precise amd64 EBS (Asia North-East)

Start the instance with an extra volume of 1 GiB, which will persist after termination (/dev/sdb=:1:false). Pass the script debigen-install-installer-cloud (see below).

HELPER_INSTANCE=$( euca-run-instances \
        --instance-initiated-shutdown-behavior terminate \
        --instance-type t1.micro \
        --block-device-mapping /dev/sdb=:1:false \
        --user-data-file debigen-install-installer-cloud \
        $HELPER_AMI  
        tee /dev/stderr   grep INSTANCE   awk ' print $2 ')

Wait that the boot finished.

while [ ! $(euca-describe-instances $HELPER_INSTANCE   grep INSTANCE   cut -f 6   tee /dev/stderr) = "running" ]
    do sleep 30
done

Get the volume's identifier

TARGET_VOLUME=$( euca-describe-volumes  
        grep $HELPER_INSTANCE   grep '/dev/sdb'  
        tee /dev/stderr   awk ' print $2 ')

Wait that the scripts shuts down the instance.

while [ ! $(euca-describe-instances $HELPER_INSTANCE   grep INSTANCE   cut -f 6   tee /dev/stderr) = "terminated" ]
    do sleep 30
done

Snapshot the volume and register it as a machine image.

PV_KERNEL=aki-44992845 # Boot PV-Grub on hd0 (Asia North-East)
TARGET_SNAPSHOT=$( euca-create-snapshot $TARGET_VOLUME  
        tee /dev/stderr   awk ' print $2 ')
while euca-describe-snapshots $TARGET_SNAPSHOT   grep -q pending ; do sleep 30 ; done
euca-register \
    --name test_di \
    --description test_of_debian_installer \
    --snapshot $TARGET_SNAPSHOT \
    --kernel $PV_KERNEL \
    --architecture x86_64

Here is the script called debigen-install-installer-cloud, used above.

#!/bin/sh -ex    
mke2fs -L debian-installer /dev/xvdb -F
mount LABEL=debian-installer /mnt/
cd /mnt    
ARCH=amd64
DIST=squeeze
DI_VERSION=20110106+squeeze4+b2
MIRROR=jp
BASEURL=http://ftp.$MIRROR.debian.org/debian/dists/$DIST/main/installer-$ARCH/$DI_VERSION/images/netboot/xen
wget $BASEURL/initrd.gz $BASEURL/vmlinuz    
mkdir -p boot/grub    
cat > boot/grub/menu.lst <<__END__
default 0
timeout 3
title  Debian Installer ($DI_VERSION $ARCH)
root   (hd0)
kernel /vmlinuz root=LABEL=debian-installer ro console=hvc0 auto=true priority=critical url=http://169.254.169.254/latest/user-data DEBIAN_FRONTEND=text
initrd /initrd.gz
__END__
sleep 30     
halt

A Debian package contains some metadata about the packaged program. For instance, its homepage URL is stored in the source package control file (debian/control) and propagated through the Debian source control file (.dsc). The problem with this approach is that to update the metadata, one has to update the whole package. Today, thousands of Debian source packages are developed in a version control system, most often Subversion or Git. The repository's URL is also propagated through the control files mentioned above. It is then possible to monitor the main branch to detect and propagate changes without needing to upload to the Debian archive. In 2009, I proposed to centralise metadata about Upstream in a YAML-formatted file, debian/upstream. We are now using it in the Debian Med project to propagate bibliographic references about the manuscripts describing the packaged programs. The references can be seen on our web sentinels for our metapackages. The data transits through the Ultimate Debian Database (UDD). Let's imagine that the concept gains success and that thousands of packages provide a debian/upstream file. How can we avoid thousands of daily requests on Alioth to keep the database up to date ? I am developing a system called Umegaya, for Umegaya is a MEtadata GAtherer using YAml. Umegaya provides a web interface with a simple URL structure to retrieve data. For instance, http://upstream-metadata.debian.net/emboss/reference-year returns 2000, the year where the first scientific article describing EMBOSS was published. If at the time of retrieval, the previous update was older than one hour, the system will read the package's debian/upstream file again. It is therefore by reading the data that it is kept up to date. Conversely, to update the database after modifying debian/upstream, one just has to access it. Umegaya is still a draft, and many things may change. But the service is already up for more than a year at the address upstream-metadata.debian.net. It is used to fill the Subversion repository called packages-metadata, with gathers the debian/upstream, debian/control and debian/copyright files from recently uploaded packages (since a few months). One can see there that among the 3,646 copyright files, 1,218 declare themselves conformant to the machine-readable format 1.0. Because I like a lot the principle package what you use, use what you package, umegaya entered the Debian archive a few days ago.

It is rare that I use social networks, but usually I do not decline invitations to connect when they come from people I know. This said, I had doubts when accepting invitations from other Debian Developers, most of whom I never met in person: how can I be sure that the account really belongs to the person ? Luckily, we have a tool to solve that problem, our GPG key ring. I have signed the URLs of my pages on some networks, and from now I decided to only accept invitations to connect that are certified by this way or another, when they originate from somebody having a key. Paradoxically, although most social networks do not redistribute the source code of their systems, the only time I really used one was for Free software, by contacting a former developer whose email address was not available anymore, in order to clarify the license of one piece of code he wrote long time ago, that way saving one of my packages from being exiled in the non-free area.

With L szl B sz rm nyi we adopted mime-support, which was maintained since September 1996 by Brian White. It is the first package of standard priority that I take care of. It gives me the same feeling as when side wheels were removed from my bicycle, a long, long time ago. We transferred the source package on Alioth, and uploaded a first update allowing the extraction of information for the mailcap file directly from Desktop files. I think that the next two works will be to resolve the bug about the handling of PHP files, and to update the mime.types base, if possible in synergy with Fedora or other distributions.

Each instance (virtual machine) started from the same image is configured identically. The same account and the same procedure will be used to connect to it. If the machine image is public and if the instance is open to the Internet, which is common when using commercial providers such as Amazon, an attacker could connect randomly to known IPs from the cloud, and eventually access to an instance before its owner. To individualise the connection to each instance, one can pass informations at startup, called instance metadata, which will be available to this instance only at a fixed HTTP URL. If the owner provides a public SSH key, this can be used to ensure that only the owner of the private key can connect. After the next update of network-console, this method of connection will be available for the Debian Installer. Likewise for the Debian images produced, by installing the cloud-init packages, that I uploaded to the experimental section of our archive. This package is far from ready. It lacks init scripts, it is not translated, and to be honest, I have not tested it. But to have it in Debian makes me benefit from the package and bugs tracking systems. Do not hesitate to report some, or better, to participate to the maintenance of this package. Cloud-init has many other interesting functionalities. I would like to thank Scott Moser, the upstream developer and maintainer of the Ubuntu package, for his cooperation during the creation of the Debian package, as I made large modifications, in particular the removal of the part managing the menu.lst for pv-grub, which will have its own package or will be transferred somewhere else.

Debian Med prepares a metapackage for multi-purpose image machines, containing packages for bioinformatics that can be used in command line or via scripts, and that do not depend on too many other packages. I would like to prepare such an image for the Amazon cloud in the most secure manner, and the simplest way is to build it automatically in order to not have to clean anything at the end of the process. I tried for months so use the Debian installer, but banged my head against walls repeatedly, as it was impossible to re-partition the volume on which the installer was started. In the end, I figured out that this was not necessary. For instance, one can start an image containing the installer on a micro instance (-t t1.micro), with an additional volume of one gibibyte (-b /dev/sdb=:1:false) to install Debian on, and preseed the installer via instance metadata (-f preseed.txt) using a file prepared in advance. When the installation finishes, the instance terminates instead of stopping (--instance-initiated-shutdown-behavior terminate), and its volumes disappear, except the one where Debian was installed (/dev/sdb=:1:false). Debian-installer in Stable is not often updated, and its size is very small. One can therefore think of releasing one machine image per zone and architecture. I did so for T ky (ap-northeast-1) on amd64. It contains the kernel, its initrd, and a GRUB 1 menu for pvgrub, that passes the following options: console=hvc0 auto=true priority=critical url=http://169.254.169.254/latest/user-data DEBIAN_FRONTEND=text. Two key pieces are missing in the resulting system. When the kernel is installed or updated, the GRUB 1 configuration file for pvgrub must be refreshed. Also, the system must be able to retrieve a public SSH key provided through the instance metadata, to allow one to log in without using a predefined password. These two functions are provided by the cloud-init package, available in Ubuntu and Fedora. I am looking for volunteers to maintain or co-maintain cloud-init in Debian.

Hi,

in this bits:

1. Debian Med Bug Squashing Advent Calendar 2011
2. Anniversary of Debian Med
3. Second Debian Med sprint (Southport, 27th-29th January 2012)
4. Mentoring of Month (MoM)
5. DDs who came to Debian because of Debian Med
6. Future plans
7. General lessons learned
   

Debian Med Bug Squashing Advent Calendar 2011In December last year Thorsten Alteholz has started a nice QA initiative which might be interesting for other teams next Advent. The Debian Med team was able to fix about 70 bugs in this time. Thanks to Thorsten for this nice piece of motivation and thanks to everybody who took part in the bug squashing.

Anniversary of Debian MedOn Mon, 7 Jan 2002 the Debian Med project was first officially announced. I submitted a short blog posting about this and perhaps you might like to see a long sequence of talks about this topic.

Second Debian Med sprint (Southport, 27th-29th January 2012)In end of January 2012 the Debian Med team has met to the second sprint. As last year I would call this a very successfull event and I would recommend other teams to instanciate such meetings as well. Feel free to read my more verbose report.

Mentoring of Month (MoM)I have started this project for the following reasons:

• gather more manpower to the team
• strengthen connections to upstream (which might become MoM students)
• help shy people to become more verbose
• to learn myself about potential problems of people who do not feel fit for packaging tasks

I made a short summary how the first MoM project worked (see at bottom).

DDs who came to Debian because of Debian MedAfter realising that several members of the Debian Med team finally became DDs I made a little survey to find out about their reasons to become DD / DM. I came to the conclusion that a Blend could be a nice entry point for people to join Debian because newcomers can identify themselves with a known topic (the scope of the Blend - in this case medicine and bioinformatics) first and learn Debian rules in a team with common interest. This perfectly fits my expectation which I had from the beginning 10 years ago and I would be very happy if other Blends would follow this example to be nice, inviting and try to *actively* ask people for cooperation (see some simple rules which I learned in this process below). In the teammetrics GSOC project some graphs were created where you can see the level of contribution of these people (and other team members).

Future plansCurrently some heavy work regarding bringing bibliographic references about packages straight into package information is going on. This topic is specifically interesting in Biology because programs are frequently connected to some publication about the methods used inside the code. This topic is as well relevant to Debian Science and DebiChem. Thanks to the patient work done by Charles Plessy we now have about 70 packages featuring debian/upstream files featuring bibliographic references and there is ongoing work to move these data to UDD to enable further usage. We are in the process of final polishing the format and finishing scripts for the import. If people are interested to join this effort this would be the right moment to raise their hand.

General lessons learned

1. Do not let wait anybody who wants to do work.
2. Newcomers are frequently shy - try to invite them kindly and patiently.
3. Tell people verbosely about your project - it is astonishing how less people know and what wrong assumptions they make about your project.

Kind regards
Andreas.

Four and a half years after Sam Hocevar started a draft proposal on the Debian Wiki, we've published revision 1.0 of the machine-readable format for debian/copyright files. The format (as DEP-5) has been in widespread use for some time, but there have been multiple versions of the format and multiple transitional versioned URLs. Everyone can now update to the same version of the document and use a stable format URL. Below is the text of the annoucement that I just sent to debian-devel-announce. Version 1.0 of the machine-readable format for debian/copyright files (the culmination of the DEP-5 process) has now been published. The canonical URL (and also the URL to use in the Format field in such files) is:

http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/

For those who have adopted various iterations of the DEP-5 format for your packages, please consider updating to this format the next time you revise your package. Use of this format in Debian packages is optional. Thanks to all of the people who have contributed to this work over its long evolution. Particular thanks go to Steve Langasek, Charles Plessy, and Lars Wirzenius, who kept this document moving through its extended DEP discussion process, and Sam Hocevar, who started this work in 2007. The copyright format specification is now being maintained as part of the debian-policy package and will follow the same update process that's used for other parts of Policy. See:

http://wiki.debian.org/PolicyChangesProcess

for that process. For this specification, we're trying something new for Debian technical policies. This document is versioned, and older versions of the specification will be maintained to not invalidate older references in copyright files that have not been moved to newer versions. This is similar to the way that specifications are handled by some other projects, particularly the freedesktop.org standards. The plan, going forward, is that informative changes (changes that do not change the requirements or the contents of compliant copyright files) will be made following the same relaxed procedure as other informative changes to Policy, and new versions will only informative changes will be published with the same version number. So the existing 1.0 document may receive further improvements in wording, examples, or similar changes that don't modify its meaning. Normative changes (changes that change requirements for compliant files, which includes addition of new standardized license short names) will follow the normative Policy change process, including formal seconds. Once normative changes are accepted, the next release of this specification will receive a new version number (1.1, for example). The previous version, prior to the normative changes, will be frozen, and from that point forward will not be changed except as required to continue to publish it. This includes further informative changes. We will continue publishing these frozen older versions of the standard on www.debian.org and in the debian-policy package for some time: possibly forever, and at least as long as they're still referred to by packages distributed by the project. The hope is that this will provide a good balance between specification stability, editing for clarity, and specification changes to meet changing requirements, while not invalidating the URLs in older files and while continuing to provide the information required to interpret older files.

It is since two days that all my emails, @debian.org included, are in parked somewhere between the sender and my MX, as my server broke at a moment where I strictly had no time (dealine for a grant application). It is an OpenRD Ultimate with a second hand SSD. I was quite happy to have an ARM system available to test some packages like T-COFFEE, but it looks like I will have to do without. Apparently, the machine permanently reboots. I did not manage to access to the USB serial port; there are no 10 seconds where the USB port is not disconnected / reconnected. Both ethernet port LEDs blink together synchronously with the disconnections. Removing the drive did not solve the problem. The SSD itself is fine, and I did not find in the logs hints for software problems. Strange coincidence, the last log file that was modified is daemon.log, which indicates the connection of so-called megumi-PC to our unprotected, but to my knowledge never visited, wireless network. After this, nothing.

Saturday started well, reading two stimulating articles on Planet_Debian. One about GitTogether2011, and the other about the use of Git in the Baserock company. I like a lot the idea of using Git beyond source code management. This article is itself distributed via a network of Git repositories. For the Debian package I develop and that are maintained with Git, I started some time ago to store their build logs in a branch that I called meta. Since sbuild can filter some variable chains in its logs, the command git diff --word-diff=color became a nice tool to inspect the difference between two package builds. Here is for instance the update I made this morning for bedtools: we can see that -D_FORTIFY_SOURCE=2 is not passed anymore, and that consequently the -Wunused-result warnings disappeared. Another advantages of storing build logs is simply to make available information that was not previously: buildd.debian.org contains the build logs for every architecture except the one used by the package maintainer, often one of the most popular architectures, because the uploads combine source and binary packages. This problem will be solved when our archive will automatically rebuild the binary packages uploaded with the source packages, but it will not be entirely solved as it is still possible to upload binary packages alone. In the meta branch of my Git repositories, the logs are kept side-to-side for every architecture. I am unsure if that the best layout, but for the moment I am uncomfortable with having too many parallel branches. I am starting to automate the work with the logs, for instance with that small script to gather them from buildd.debian.org.

#!/bin/bash
BASEURL=buildd.debian.org:/srv/buildd.debian.org/db
PACKAGE=$1
shift
for version in "$*"
do
  scp $BASEURL/$ PACKAGE:0:1 /$PACKAGE/$ version /* .
  for arch in $(ls *bz2   sed 's/_.*//g')
    do bzcat $ arch *bz2 > $ arch .log
    rm $ arch _*_log.bz2;
  done
done
exit

It has been a long time I want to prepare a pure Debian virtual image for the Amazon elastic computer cloud, that would contain the bioinformatics tools that we package in Debian Med. Most methods discussed in the ec2debian group use debootstrap, and finish the preparation with external scripts. Now that Amazon Machine Images can boot on their original kernel, I am exploring the use of the debian installer to setup a pristine system on a elastic block storage volume. The Debian installer can be booted with GRUB and preseeded through a file downloaded early after starting. In the Amazon cloud, this file can be put at http://169.254.169.254/latest/user-data with the other instance metadata. Since I am not much experienced in this field, I progress slowly on automating the procedure. For the moment, preseeding is not comprehensive, but at least the installer's SSH console is started. Ideally, one should connect using a key, but for the moment I go with a password. Currently, I am stuck with the partitioning of the hard drive: No root file system is defined . Here are a couple of technical details. I use the cheapest instances, t1.micro (32 bits) for the tests. I downloaded debian-installer on an elastic volume of 1 Gb, that I formatted in ext2. Not knowing if the device name will stay stable (/dev/sda1 or /dev/xvda1), I flagged the partition, as I have seen in Ubuntu virtual machines.

ARCH=i386
DIST=squeeze
DI_VERSION=20110106+squeeze3
MIRROR=jp
BASEURL=http://ftp.$MIRROR.debian.org/debian/dists/$DIST/main/installer-$ARCH/$DI_VERSION/images/netboot/xen
mke2fs -L debian-installer /dev/sdb -F
mount LABEL=debian-installer /mnt/ && cd /mnt/
wget $BASEURL/initrd.gz $BASEURL/vmlinuz
mkdir -p boot/grub
cat > boot/grub/menu.lst <<__END__
default 0
timeout 3
title  Debian Installer ($DI_VERSION $ARCH)
root   (hd0)
kernel /vmlinuz root=LABEL=debian-installer ro console=hvc0 auto=true priority=critical url=http://169.254.169.254/latest/user-data
initrd /initrd.gz
__END__

A snapshot of this volume can then be registered as an image machine. The kernel to use will depend on whether the system has been installed in the whole volume or a partition. Debian distributes tools for all these operations, such as euca2ools.

Two weeks ago, I updated the packages containing the BioPerl modules bioperl and bioperl-run, which allowed to resume the work done on GBrowse, one of the genome browsers available in Debian. As many Perl modules, BioPerl has extensive regression tests. Some of them need access to external services, and are disabled by default as the Internet is not available in our build farm. Nevertheless, they can be triggered through the environment variable DEB_MAINTAINER_MODE when building the package locally. Bioperl successfully passes all off-line tests, and a part of the on-line tests is already corrected its development branch. In contrary, BioPerl-Run fail the tests for Bowtie, DBA, EMBOSS, Genewise, Hmmer, PAML, SABlastPlus, T-Coffee and gmap-run. In some cases, like EMBOSS, it is because a command has been renamed in Debian. In other cases, in particular DBA et Genewise, it is much more difficult to figure out on which side is the problem. Regression tests are essential to determine if a package works or not on ports others than the one used by the packager (amd64 in my case). Even simple ones can be useful. In the case of T-Coffee, that has a rudimentary test that I have activated recently, it showed that the packages distributed on armel are not working at all. Running regression tests when building packages have advantages, in particular to have the results published for each port automatically as part of the build logs. But is also cause problems. First, a package would need to build-depend on every software it can interact with, in order to test it comprehensively. In the example of bioperl-run, it makes it impossible to build on armel as long as t-coffee is broken there. Second, this approach does not help the user to test similarly a program installed on his computer. Maybe the Debian Enhancement Proposal 8, to test binary packages with material provided by their source packages, will solve these two problems.

GBrowse, a genome browser, is packaged for Debian since three weeks. It is the result of a work started four years ago, and I am especially grateful to Olivier Sallou for having unblocked and finished the project while I was starting to go round in circles, and to Aaron M. Ucko for repairing the new package, that was not compatible with our build farm. GBrowse and similar software, like IGV, are used for graphical representation of a chromosome and its annotations, such as the gene positions and markers of their activity, and in particular the result of experiments using high throughput DNA sequencing. A Debian Med task is actually dedicated to gather programs for that topic. In a couple of years, it may be possible that any person who wants can sequence his chromosomes, that is, his genome. This will revolution medicine and perhaps break some founding myths. Even if software for the general public will look different, packages like gbrowse are a first step towards a better access of the public to his medical data. Work continues on GBrowse, with the goal of being able to install it with a reference version of the human genome with a command like apt-get install human-genome. The next step will be to update BioPerl, used by GBrowse, to version 1.6.9.

Since I m soliciting donations to support my Debian work, the least I can do is explain what I do. You can thus expect to see an article like this one every month. Multi-Arch work I updated the code to use another layout for the control files stored in /var/lib/dpkg/info/. Instead of using a sub-directory per architecture (arch/package.type), we decided to use package:arch.type but only for packages which are Multi-Arch: same. dpkg is taking care to rename the files the first time it is executed with write rights and then updates /var/lib/dpkg/info/format to remember that the upgrade has been done and that we can rely on the new structure. I filed a few bugs on packages that are improperly accessing those internal files instead of using the appropriate dpkg-query interface. I sent a heads-up mail on -devel to make other people aware of those problems in the hope to discover most of them as early as possible. After that, the work stalled because Guillem went away for 2 weeks and thus stopped his review of my work. I hope he will quickly resume the review and that we will get something final this month. With the arrival of dpkg 1.16.0, it s now possible to start converting libraries to multi-arch even if full multi-arch support has not yet landed in dpkg proper. See http://wiki.debian.org/Multiarch/Bootstrapping for the detailed plan. If you re curious about Multi-Arch, you might want to read this article of Steve Langasek as well. Bug triage for dpkg in launchpad At the start of the month, there was close to 500 bugs reported against the dpkg package in Launchpad. Unfortunately most of it is noise many of the reported bugs are misfiled, they show an upgrade problem of a random package and that upgrade problem confuses update-manager which tries to configure an already configured package. This generates a second error that apport attributes to dpkg and the resulting bug report is thus filed on dpkg. There are literally hundreds of those that have to be reclassified. Michael Vogt and Brian Murray did some triaging, and I also spend quite some hours on this task. It s a bit frustrating as I tend to mark many reports Incomplete because there s no way they can be acted upon and many of them are so old that the reporter is unlikely to be able to provide supplementary information. But in the middle of this noise, there are some useful bug reports, like LP#739179 which enabled me to fix a regression even before it reached Debian Unstable (because Ubuntu runs a snapshot of dpkg with multiarch support). I subscribed to the Launchpad bugs for dpkg via the Debian Package Tracking System (thanks to the derivatives-bugs keyword) and will try to keep up with the incoming reports. Misc dpkg work The ftpmasters came up with a request for a new field (see 619131) in source packages. After a quick discussion and a round of review on debian-policy@l.d.o, I implemented the new Package-List field. This should allow the ftpmasters to save some time in NEW processing, but we deferred the change for the next dpkg version (1.16.1) to ponder a bit more on the design of the field. I also fixed a bunch of bugs (#619541, #605719, #598922, #616096) and merged a patch of Mark Hymers to recognize the new Built-Using field. Developers-reference work The review process for changes to the developers-reference is not working as it should. And I suffered from it while trying to integrate the patch I wrote for the Developer duties chapter (see #548867). We purposely changed the maintainer field from debian-doc to debian-policy in the hope to have more reviews of suggested changes and to seek some sort of consensus before committing anything. But we don t get more reviews and deciding to commit a patch is now even harder than it was (except for trivial stuff where personal opinions can t interfere). In my case, I only got the feedback of Charles Plessy which was very mixed to say the least. I tried to improve my patch based on what he expressed but I also clearly disagreed with some of his assertions and was convinced that my wording was in line with the dominant point of view within Debian. We tried to involve the release team in the discussion because most of what I documented was about helping making stable release happen, but nobody of the team answered. Instead of letting the situation (and my patch) rot, I solicited feedback from the DPL and from another developers-reference editor to see whether my patch was an improvement or not. After some more time, I went ahead and committed it. It was not pleasant for anyone. I don t know how we can improve this. Contrary to the policy, the developers-reference is a document that is not normative, I believe the result is better when we put some soul into it. But it s a real challenge when you seek a consensus and that the interest in reviewing changes is so low. DVD shop listed on debian.org In February, I launched a DVD shop whose benefits are used to fund my Debian work. Shortly after the launch I used the official form to be added to the official listing of Debian CD vendors and offered a few suggestions to deal with vendors who are selling unofficial images (with firmware in my case). A few weeks later, I got no answers: neither for my request nor for my suggestions, I mailed the cdvendors@debian.org team directly asking for a status update and quickly got an answer suggesting that Simon Paillard usually does the work and can t process the backlog due to some injury. At this point no concerns had been raised about adding me to the list. To save some time and some work for the team, I added myself to the list since I had commit rights and I informed them that I did it, so that they can review it. Shortly after I did that, Martin Zobel Helas objected to my addition. I cleared some misunderstandings but the discussion also lead to some changes to please everybody: the listing now indicates that some images are unofficial and I have prepared a special landing page for people coming from the Debian website through this listing. Debian column on OMG! Ubuntu I have always been a firm believer that it s important for Debian to reach out to the widest public with its message of freedom. Thus when Benjamin Humphrey contacted the debian-publicity team to find volunteers to write a Debian column on OMG! Ubuntu, I immediately jumped in. I wrote 4 articles over there. The tone is very different from my articles on my blog and I like that duality. Check out Debian is dying! Oh my word!, Debian or Ubuntu, which is the best place to contribute?, Are you contributing your share? and Ubuntu s CTO reveals DEX: an effort to close the gap with Debian. It s a great win-win situation, OMG! Ubuntu benefits from my articles, Debian s values are relayed further, and OMG! Ubuntu s large audience also helps me develop my own blog. Work on my book I had lots of paperwork to do this month (annual accounting stuff for my company) and I did not have as much time as I hoped for my book. Still I have a updated a few more chapters of my French book and I certainly hope to complete the update during April. This means that the work on the English translation could start in may. Work on my blog Just like for my book, it has been relatively difficult for me to cope with my policy of two articles every week. But I still managed to get quite some good stuff out. I interviewed Christian Perrier (Debian s translation coordinator) and also Bdale Garbee (chair of Debian s technical committee). I finished my series of Debian Cleanup Tips with 2 supplementary articles:

• Identify cruft that can be removed from your Debian system
• Remove automatically installed packages

The removal of firmware is causing troubles to quite some users so I wrote an article explaining how to deal with the problem. A regular reader also asked me to write an article about Jigdo, I executed myself because it was a good idea and that he has been very nice with me: Download ISO images of Debian CD/DVD at light speed with Jigdo. Last but not least, I shared my package maintainer pledge which inspired my developers-reference patch (see discussion above). Thanks Many thanks to all the people who showed their appreciation of my work. The 324.37 EUR that you gave me in February represented 2 days and a half of my time that I have spent working on the above projects. See you next month for a new summary of my activities.

2 comments Liked this article? Click here. My blog is Flattr-enabled.

For the second time, I chose an iMac as a computer at work. I like a lot its simplicity. Only one cable, few options, a big screen and that's all. The other manufacturer where it is easy to order has a complex offer. Is the computer for playing ? for the office ? at home or in a company ? A public one, a private one ? I nervously installed Debian as soon as the machine arrived. What if it did not work, would I have to use OS X for the next three or four years ? Luckily, everything went well, and the procedure is much simpler than it looks: install rEFIt, shrink the system partition with diskutil, add two partitions for Debian and its virtual memory with Disk Utility, and restart on the Squeeze installation CD-ROM, be guided by the installer, make sure to install the GRUB on the Debian partition, not on the master boot record. Just in case I would suddenly need it, I also installed the proprietary ATI drivers, that provide graphical acceleration. I then installed Grid Engine, to take the best out of the hyper-threaded four cores of the processor. The README.Debian file is very clear and allows a simple configuration in a couple of minutes. Being a beginner, I still had to try two times, because at the beginning I was using localhost instead of a more proper name for the machine. It also took me some time to find two key parameters: slots for executing multiple jobs simultaneoutly, and priority to avoid the calculations freeze my desktop, because it is still just a desktop computer. I do not know if under OS X recent iMacs heat that much, but in these times of heater restrictions, I can conveniently heat my hands on the aluminum case of the machine. However, I am a bit worried for this summer, when restrictions will be on air conditioning.

Out of curiosity, and because it is Sunday morning and I have a cold and can't get my brain to do anything tricky, I counted the number of candidates in each year's DPL elections.

Year	Count	Names
1999	4	Joseph Carter, Ben Collins, Wichert Akkerman, Richard Braakman
2000	4	Ben Collins, Wichert Akkerman, Joel Klecker, Matthew Vernon
2001	4	Branden Robinson, Anand Kumria, Ben Collins, Bdale Garbee
2002	3	Branden Robinson, Rapha l Hertzog, Bdale Garbee
2003	4	Moshe Zadka, Bdale Garbee, Branden Robinson, Martin Michlmayr
2004	3	Martin Michlmayr, Gergely Nagy, Branden Robinson
2005	6	Matthew Garrett, Andreas Schuldei, Angus Lees, Anthony Towns, Jonathan Walther, Branden Robinson
2006	7	Jeroen van Wolffelaar, Ari Pollak, Steve McIntyre, Anthony Towns, Andreas Schuldei, Jonathan (Ted) Walther, Bill Allombert
2007	8	Wouter Verhelst, Aigars Mahinovs, Gustavo Franco, Sam Hocevar, Steve McIntyre, Rapha l Hertzog, Anthony Towns, Simon Richter
2008	3	Marc Brockschmidt, Rapha l Hertzog, Steve McIntyre
2009	2	Stefano Zacchiroli, Steve McIntyre
2010	4	Stefano Zacchiroli, Wouter Verhelst, Charles Plessy, Margarita Manterola
2011	1	Stefano Zacchiroli (no vote yet)

Winner indicate by boldface. I expect Zack to win over "None Of The Above", so I went ahead and boldfaced him already, even if there has not been a vote for this year. Median number of candidates is 4.

Someone asked me during CeBIT for official packages of mendeley. I didn't knew much about it at that time, but mentioned it in my report on the debian-project mailing list. It appears, that mendeley won't be packaged anytime soon, however Charles Plessy and others commented on that and mentioned some similar tools. As I don't have any contact data for the visitor, who asked me about it, the best thing I can do for now is mention it here, so he might notice it and read the comments on the list.

Now that maintain several dozens of packages in Debian, I think twice before uploading a new one. Does it have a future, a public ? Some of the packages I prepare are available on git.debian.org, and are listed in Debian Med's tasks pages. It would not take me long to finish most of them, but that does not take into account the time others will spend on it. They will make our archive bigger and our quality tests longer to execute. Somebody will translate their description. Somebody else will perhaps write a security patch someday, or a patch to make the package compilable with a new version of GCC. All in all, each package has a footprint in Debian's ecosystem. That footprint starts early, as soon as the package is sent to the NEW queue. For instance, I kept by mistake some old content in the copyright file of clustalw, that was recently freed and has to go through the NEW queue to be transferred from the non-free to the main area of our archive. That costed a small of exchange of emails, that could have been avoided. Our packages should be perfect, but that is difficult to achieve alone. For that reason, I proposed two years ago a package review system, that functions like a chain reaction. The principle is simple. After uploading to the NEW queue, download two neighbor packages and check their copyright file. The errors found can be corrected by their maintainer before the the FTP team inspects it, which save their time. For instance, after uploading tabix, I found an error in mediathekview, that was corrected. That compensates for my mistake with clustalw. If each person receiving a package review does a review of two other packages, that will create a chain reaction that will clean the queue from the simplest mistakes, leaving only the really problematic cases. As Torsten noted recently, the NEW queue is getting long. So how about trying to help ?